fix(playground): resolve dev server crash caused by Next.js 16 upgrade#1215
fix(playground): resolve dev server crash caused by Next.js 16 upgrade#1215mishop-15 wants to merge 2 commits intoasyncapi:masterfrom
Conversation
There was a problem hiding this comment.
Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
|
Hi @AceTheCreator, I noticed the playground build was broken after the recent Dependabot upgrade to Next.js 16 (Turbopack conflict). I've submitted this fix to resolve the crash and clear up the config warnings so the dev server runs smoothly again. Ready for review whenever you have a moment! |
AceTheCreator
left a comment
There was a problem hiding this comment.
Thanks for fixing this. One note from my review: since Next.js 16 ships with Turbopack, I think we should use it instead of Webpack. I’d suggest removing the Webpack configuration and switching fully to Turbopack.
|
Thanks for the review! I'll go ahead and remove the custom Webpack configuration and switch the dev script to use turbo. Updating the PR shortly! |
I’ve updated the script to use --turbo, but I'm hitting a build error because the parser dependencies rely on Node.js modules like fs. Unlike Webpack (which let us just set fallback: false), Turbopack doesn't polyfill these by default yet. To resolve this, I would need to implement a workaround since Turbopack lacks the fallback: false configuration that Webpack uses to ignore server-side modules. The solution involves creating a small, empty mock file for fs and configuring an alias in next.config.js to redirect all fs imports to this local file. Are you comfortable with me adding this mock to the repository, or should we prefer to stick with Webpack. |
|
Please mention issue number in the PR description |
There isn't an issue associated issue raised with this. I encountered while setting up the project locally. |
Yes, please go ahead, cuz it seem that's the recommended approach for fallback in turbopack 👍🏾 |
|
@AceTheCreator I gave the Turbopack approach a try but hit some walls. Started by creating The bigger issue is that AsyncAPI's parser dependencies ( My original Webpack solution ( |
Yeah, you're right. I totally forgot about the Parser 😄 Let's use the webpack flag for dev |
|



Context
The
playgroundpackage was recently upgraded from Next.js 14 to 16.1.5 (via Dependabot ~2 days ago).The Issue
Next.js 16 enables Turbopack by default for development. However, this project uses a custom webpack configuration in
next.config.mjs. This causesnpm startto fail immediately with a conflict error because Next.js cannot use both Turbopack and a custom Webpack config simultaneously without an explicit flag.The Fix
startscript inplayground/package.jsonto add the--webpackflag. This forces Next.js to use the existing webpack config.eslintkey fromnext.config.mjs(which is no longer supported in Next.js 16 and was throwing warnings).next.config.mjsto theincludelist inplayground/tsconfig.jsonto resolve local ESLint parsing errors.Verification
Validated that
npm startnow successfully launches the playground onhttp://localhost:3000.